System and method for realistic terrain simulation

ABSTRACT

A technique and system for the realistic simulation of visual scenes reduces the three-dimensional computation to two additions and further reduces the need for three-dimensional computations by displaying several screen pixels per three-dimensional computation. The approach when implemented in hardware or software significantly speeds up scene generation time while improving the resolution and realism of the rendered scene.

FIELD OF THE INVENTION

[0001] This invention generally relates to a technique and system forthe generation of images on a display device, and more particularly toreal-time computer simulation of visual images of perspective scenessuch as landscapes and seascapes.

BACKGROUND OF THE INVENTION

[0002] The principal application area for computer image generation hasbeen that of visual training and/or entertainment simulators whichpresent scenes to an operator, usually a trainee or game player, thatallows the operator to practice some task such as flying an airplane,helicopter or space vehicle. In a flight simulator, a three-dimensionalmodel of a desired “gaming area”, called a visual data base, is preparedand stored in memory of a computer. Typically, the visual data base isan array of points, generally in the form of Cartesian coordinates. Invisual data bases of this type, the z component associated with each x,y position may be an elevation value, or some other attribute requiredto produce a visually pleasing scene, such as color, hazing, viscosity,or the like.

[0003] In its usual configuration , the simulator combines an imagegenerator, typically a computer, with a display device such as a cathoderay tube (CRT) or liquid crystal display (LCD). The image generatorconverts the three-dimensional visual data base into a two-dimensionalscene for display on the display device. The generated imagery is meantto be representative of the true scenes that the operator would see ifthe operator were actually performing the task being simulated. Thegeneration of display images is said to be in “real time” if the imagesare updated fast enough to provide the operator with a sense of motion.

[0004] Real-time generation of visual scenes is usually a compromisebetween realism and the cost of the image generator and the displaydevice. Generation of visually pleasing and realistic appearing imagesrequires the manipulation of substantial amounts of data by the imagegenerator. This manipulation typically requires a high speed processorand a large amount of associated memory for storing both the raw dataand the rendered image. In the past, various techniques have beenemployed to accelerate processing of the visual data during scenerendering, usually at the cost of reduced resolution and realism. Manyprior techniques rendered the terrain of the gaming area using so-calledpolygonal projections. This type of visual scene rendering, whileadequate for simple games, or for games where the focus of attention isnot on the overall visual scene, lacks the realism important toproviding the user with a true simulation of the operation of theaircraft or vehicle simulated. Such realism is particularly importantwhere the operator of the game is engaging in simulated combat, such asin a dog fight or tank battle. The simulation has two parts: 1) theoperation model that simulates the actual operation of the plane orvehicle in response to operator inputs. For example, in a flightsimulation, the operator must be presented with a flight model thatmimics, as closely as possible, the actual flight characteristics of theplane being simulated. The flight model must present the operator with arealistic flying experience, mimicking the responses of the aircraft ina wide variety of situations.

[0005] Typically, a flight model must provide a realistic simulation ofthe aircraft's response to changes such as operator inputs controllingclimb, descent, banking for maneuvering, as well as determining whetherthe aircraft is in level flight or landing or taking off. While theprocessor is controlling the flight model, it must also associate themovements of the aircraft with motion over the ground. Thus, theprocessor must also render and update a visual scene representing asimulated “world” that is experienced by he operator as the operator“flies” the aircraft through the simulation.

[0006] Rendering a realistic visual scene at a rate that provides avisually pleasing and realistic experience places a heavy load on theprocessor. This, it is important to optimize the rendering of the scentto reduce processor load and data transmittal. In these simulations muchof the action involves use of the features of the terrain, either forpurpose of evasion or to lend difficulty to enemy detection and attack.

[0007] One prior approach to presenting more realistic terrain to avirual observer moving through a gaming area is described in U.S. Pat.No. 5,550,959 issued to Freeman. This approach forgoes the simplicity ofpolygonal feature and uses a technique based on volume elements. In thisapproach, the visual data base contains elevational and color dataassociated with each point in an array of points defining a gaming area.The location of the operator in relation to the coordinates of thevisual data base is determined from the operator's starting position inthe gaming area and the operator inputs. The terrain generator uses thisinformation to divide the area of the visual scene visible to theoperator into a number of cross-sections oriented perpendicular to theline of sight of the operator. The horizontal scale of thecross-sections changes proportionately to the distance from theoperator, as does the vertical scale of the terrain features beingdisplayed. The horizontally and vertically scaled visual scene isgenerated one cross-section at a time until the entire scene isrendered, and then displayed. Alternatively, each point on a series ofindividual cross-sections can be generated, stepping backwards orforwards through the cross-sections. One disadvantage of this approachis that the distance to the visible horizon is limited, resulting interrain features suddenly appearing on the horizon as the operator movestoward the horizon. Another problem arises as an operator moves towardan object or terrain feature. In this case, the resolution of thefeature is limited to the size of the smallest volume area in the database. This results in terrain features rendered with a visuallyunrealistic and unpleasing blocky appearance. Another shortcoming ofprevious methods of terrain generation using volume elements has beendifficulty in providing motion in all axes, known as pitch, yaw androll. Because horizontal and vertical scaling were necessarily fixed toenhance processing speed, prior techniques could provide virtually noadjustment for pitch or roll. The lack of such features is detrimentalto the level of realism achieved by the simulation, and thus isdisadvantageous in providing the kind of exciting and visually pleasingsimulation sought by a game player.

[0008] Additionally, game developers were constrained by the relativelyslow processing speed of available processors incorporated in computersand gaming devices, slow data transfer rates across the internal bus ofthe computer or gaming device, and the amount of rapidly addressablerandom access memory available for storing the data comprising thevisual image to be displayed. With the advent of 4×86 and other advancedprocessors, VESA and PCI bus architecture and the availability ofinexpensive memory, developers are now able to utilize moresophisticated data retrieval and display techniques without sacrificingexecution speed of the simulation.

[0009] What has been needed is a technique for real-time generation ofvisual displays without sacrificing realism or requiring expensivehardware.

SUMMARY OF THE INVENTION

[0010] The invention provides a unique real-time display of visualscenes rendered by a computer in accordance with programming commands toprovide a realistic and visual pleasing simulation. The inventionprovides this real-time display of visual scenes by rendering the scenesby altering the scaling of the visual scenes in accordance with thedistance of a virtual observer from features in the visual scene to bedisplayed. The present invention accomplishes the more realisticrendering of visual scenes by using elevational databases whoseresolution is varied dependant upon the calculated distance of theobserver to features that are to be displayed.

[0011] More particularly, the invention may draw upon a series ofdatabases, each database containing more information, and thus higherresolution, than the preceding database. Thus, the same feature to berendered is contained, at varying resolution, in more than one database.

[0012] Moreover, the invention may enhance the resolution of featuresthat are relatively close to the virtual observer by expanding the dataused to render the feature using expansion tokens that may point tostored images or portions of images that may be rendered or mapped intothe visual scene. The invention determines when to expand the datadepending on the distance between the feature to be rendered and thevirtual observer. In this manner, the invention may render a singlevisual scene using more than one database containing elevational and/orcolor data for individual features in the scene, depending on theapparent distance between individual features and the virtual observer.

[0013] Because the enhanced rendering of visual scenes requiressubstantial processing time by the computer, the invention provides foridentifying quadrants of the visual scene to be displayed withelevational databases associated with the quadrants wherein a singleelevation, representative of the height of the highest feature in thequadrant, is stored. In this manner, the computer, in determiningwhether individual elements and features of the visual scene are visibleto the virtual observer, or whether the elements or features areobscured by other elements or features, need only determine whether thequadrant would be visible, rather than processing each pixel element ofthe quadrant individually. Using this feature, the inventionsubstantially reduces the amount of processing required to rendercomplex and fast moving visual scenes to provide a visually pleasing andrealistic simulation experience to an operator.

[0014] Other features and advantages of the invention will becomeapparent from the following detailed description, taken in conjunctionwith the accompanying drawings, which illustrate, by way of example, thefeatures of the invention.

DESCRIPTION OF THE DRAWINGS

[0015]FIG. 1 is a block diagram of a general purpose computer systemthat is programmed by the techniques of the present invention to renderthe terrain of a simulation;

[0016]FIG. 2 is a representation in plan view of a gaming area of thesimulation, representing a virtual observer's location and headingtherein;

[0017]FIG. 3 is a representation of the gaming area of FIG. 2 as seen bya game player showing the terrain of the gaming area rendered inperspective;

[0018]FIG. 4 is a cross-sectional view of the gaming area of FIG. 3taken along the line 4-4.

[0019]FIGS. 5A and 5B are block diagrams of the image generator of thepresent invention;

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] The real-time generation of perspective scenes reflective of avirtual observer's movement through given terrain is a critical need foraviation and ground simulation trainers and many types of computergames. In order to minimize the number and complexity of the requiredcalculations, the present invention provides a method for generatingperspective scenes using data bases such as the elevation grid databases produced by the Defense Mapping Agency. Such data bases aredescribed more fully in U.S. Pat. No. 4,583,185 to Robert A. Heartz.

[0021] The technique according to the present invention may beillustrated with reference to FIGS. 2-5. Observer (virtual) location andheading with respect to the elevation data base are obtained. In itssimplest embodiment, the scene is generated by sequentially generating aseries of “slices” or cross-sections at ninety degrees to the observer'sline of sight. Adjustment is made for the observer's altitude. Eachcross-section is horizontally scaled to render the observer's field ofview, and vertically scaled to render perspective. For each point in agiven cross-section, a vertical- line is drawn to the respective scaledheight. After a pre-selected number of cross-sections have beengenerated, the scene is displayed.

[0022] An alternative approach, while consuming more computer resources,but more visually pleasing, is to use a technique similar to the “raycasting” approach commonly used for generating polygon graphic images.The method of the present invention, however, differs from the raycasting technique in that images are generated using volume elementsrather than polygon constructs to generate the features of the terraincomprising the gaming area. In general, a video display is comprised ofa number of pixels arranged in an array of columns and rows. The numberof columns and rows is dependent on the resolution of the video device,which is dependent on the amount of video memory, commonly called avideo buffer, available in the computer. A typical arrangement, forexample, of a video display 18 operating using VGA Mode 13 h is 320×200,or 64,000 pixels is illustrated by FIG. 3. In this resolution, thedisplay 18 consists of an array of pixels 320 columns wide and 200 rowshigh. In this arrangement, each pixel can be represented by a uniquecombination of values for X and Y. For example, the pixel at the topleft corner of the display of FIG. 3 is represented by the coordinates(0, 0), while the pixel located at the bottom right corner of thedisplay is represented by the coordinates (320, 320). Other resolutions,such as 1048×768, with an increased number of pixels comprising thedisplay are also possible.

[0023] It will be obvious to one skilled in the art that the areadisplayed on the display 18 is only a small portion of the gaming areathat is available for use in the simulation. The size of the gaming areais limited only by considerations of data base size, memory storage, andprocessor speed. All of these variables can be manipulated by asimulation designer to enhance the realism of the simulation.

[0024] Referring now to FIG. 1, an exemplary computer system on whichthe software techniques of the present invention runs is described.Generally, the terrain rendering techniques of the present invention maybe implemented by a general purpose computer programmed to carry out thespecific methods set forth in reference to FIGS. 5A and 5B. Typically,such a general purpose computer comprises a processor 1 which isconnected to either or both a read-only-memory 2 and/or arandom-access-memory 3. The read-only-memory 2 stores programinstructions and data of a permanent nature. The random-access-memory 3is used to store program instructions and data temporarily in responseto commands from the processor 1. For example, the random-access memory3 may store particular programs or segments of programs used to carryout specific functions, the processor 1 being response to the storedprograms to carry out the functions of the programs as if the processorwere a hardwired, dedicated device. Additionally, the random-accessmemory 3 may be used to store current data or intermediate results in amanner well known in the art. In a preferred embodiment, the processoris an Intel x386, x486, pentium or similar processor and therandom-access-memory is typically 16 megabytes of dynamic random-accessmemory or the equivalent.

[0025] The computer system also has one or more storage devices 4, suchas a hard disk drive, CD-ROM, floppy drive or other storage mediaoperably connected to the processor. The storage device 4 may containprograms that are accessed by the processor to program the process toperform specific functions as well as data to be used by programs, suchas the present invention.

[0026] The processor 1 receives operator input from one or more inputdevices 5, such as a keyboard, joystick or mouse. Acting on the operatorinput, the processor 1 performs various operations and writes the outputof such operations to the display buffer 6, also called video memory.The contents of the display buffer 6 or video memory are written to thedisplay 18, forming an image on the display 18.

[0027] Referring now to FIG. 2, a gaming area 10 represented by a visualdata base is shown. The gaming area 10 comprises the background, orterrain, in which the simulation occurs. In a typical simulation, theportion of the gaming area 10 visible on the screen at any particulartime is only a small portion of the total gaming area 10 that is storedas an array of discrete points in the memory of the computer orelectronic gaming device on which the simulation is operated. As shownin FIG. 2, any location in the entire gaming area may be represented bythe Cartesian coordinates X and Y. The gaming area is stored in thestorage device of the computer or gaming device as strings of data, eachdata string comprising values of X and Y coordinates, and havingassociated with each X and Y coordinate a number of other values,commonly called Z coordinates. In the present invention, the Zcoordinate may comprise not only elevational data for the particularlocation represented by an individual X, Y coordinate, but may alsoinclude additional data, such as data representative of a textural valuefor the location, or color of the location, or some other attribute suchas translucence, viscosity or the like. This information may be storedin an individual data string defining each X, Y location of the gamingarea 10. Alternatively, a number of separate databases may be used, witheach data base linked by common X, Y coordinates identifying thelocation within the gaming area. Whether to store the data as onestring, or as a plurality of databases linked by common X, Y coordinatesis a decision for the game designer and is dependent on the storagecapacity of the storage media used by the computer or gaming device, andis also limited by the amount of random access memory available in thecomputer. Processing speed of the computer or gaming device is alsocritical in that the realism of the game is determined by the rate atwhich visual scenes from the gaming area 10 can be displayed.

[0028] It will be apparent that the resolution of terrain details in thegaming area 10 is dependent upon the number of locations within thegaming area 10 represented by X, Y coordinates. A gaming area has higherresolution, that is, contains more detail, when the database definingthe gaming area 10 contains more data points. Thus, infinite detailwould require an infinite number of data points, each data pointrepresenting a particular location within the gaming area and associatedwith an X, Y coordinate. At present, the degree of detail that can bemade available is limited by the amount of storage capacity andprocessor speed available.

[0029] To overcome this problem, and still provide sufficient resolutionto provide a detailed and visually pleasing simulation, prior approachesto the rendering such visual scenes reached a compromise by renderingimages having a resolution representative of the resolution of terrainfeatures located at an intermediated distances as seen by a human eye.Because of this compromise, as an observer moves through the simulation,objects that are rendered to appear as if they were located eithernearby the location of the virtual observer or at a relatively largedistance from the location of the virtual observer appear unnatural.

[0030] A further description of the terrain visible to a virtualobserver at viewpoint 12 is shown in FIG. 3. As can be seen in FIG. 3,not all of the gaming area 10 is visible to a virtual observer whosepoint of view is located at viewpoint 12, which has a particularreference point described by coordinates X, Y in the gaming area 10. Aswill be apparent to one skilled in the art, an observer situated atviewpoint 12 whose line of sight is indicated by line 14 is only able toview terrain features that are presented to the right of the areabounded by lines 16 and 18. The virtual observer's field of view,indicated by Φ in FIG. 2, may be any value desired by the gamedeveloper. In most simulations, however, a field of view comprising, forexample, 90° is preferred because this provides a realistic field ofview while not requiring inordinate amounts of processing speed ormemory to render the terrain within that field of view. It will also beapparent that besides having a location indicated by coordinates X, Y, avirtual observer located at viewpoint 12 will also have an elevationrelative to the terrain around him. In the simplest case, the virtualobserver is located in the plane of the ground as rendered in thesimulation, and thus his elevation is essentially equivalent to theelevation data associated with that particular X, Y location in thegaming area 10. In the case of an aircraft simulator, the elevation ofthe virtual observer can be substantially greater than the elevation ofthe terrain associated with location X, Y in the gaming area 10. As willbe discussed further below, the elevation of the virtual observer mustbe taken into account when rendering the scene to provide realism.

[0031] Also shown in FIG. 3 are a series of randomly drawn lines 20-28which serve as reference points to aid in describing the severalembodiments of the present invention. These reference lines 20-28represent locations of features which are located in the gaming area 10at varying distances from the location of the virtual observer. While inFIG. 3, lines 20-28 appear equidistant from each adjacent line, it willbe understood that the distance between he lines may vary depending onthe requirements of the game. For example, and not by way of limitation,the distance between each line moving towards the right of FIG. 2 couldbe twice the distance of the preceding line. Thus, terrain featureslocated along line 22 may be twice as far from viewpoint 12 as featureslocated along line 20, and features located along line 24 may be fourtimes as far from viewpoint 12 as features located along line 22.

[0032] As in real life, terrain features in a game simulation providesperspective to the game player. Thus, terrain features located in theplane of line 20, will appear larger than objects located along line 22,since they are closer to the viewpoint 12. Because of their apparentlarger size, fewer features will be able to be rendered within the fieldof view bounded by lines 16 and 18 along line 20 than may be renderedalong line 22. Accordingly, less stored information is required to beprocessed to render those features located along line 20 than isrequired to render features located along line 22. As the virtualobserver visualizes objects further and further from his location, hisfield of view becomes progressively larger and more objects need to berendered to fill the scene. At the same time, to provide the horizontalscaling necessary to provide for proper visual perspective dependentupon the distance from the observer, the relative size of each object isdecreasing. However, the data required to render the scene, for example,at line 26, is substantially greater. At some point, the amount of datanecessary to render objects along a line at a given distance fromviewpoint 12 will exceed the processing speed of the processor andtransfer rate of the bus so that further attempts to render terrain willadversely affect the rate at which the terrain can be displayed, thusslowing down the simulation and negatively affecting the performance.Accordingly, simulation developers using prior approaches to terrainrendering set an arbitrary distance for the horizon of the simulation.Because the resolution of each object was the same, objects wouldsuddenly appear on the horizon in a so-called “jack-in-the-box affect”.The appearance of large terrain features could thus prove startling anddistracting to a game player.

[0033] In a preferred embodiment of the invention, the gaming area 10may comprise a series of data bases, with each data base optimized toprovide terrain as seen by a virtual observer at a predetermineddistance. Since each of these data bases are optimized to provideterrain scaled to appear as if viewed at a predetermined distance, theoptimization of each data base could take advantage of the reduced needfor data to provide realistic resolution of the terrain features. Forexample, and not by way of limitation, separate data bases could be usedto render terrain features visible along each line 20, through 28. Forexample, while terrain features located along line 20 are closest toviewpoint 12 and thus require the highest resolution to provide arealistic visual scene, the number of features visible within the fieldof view bounded by lines 16 and 18 is substantially less than the numberof features similarly located within the field of view along lines22-28. However, because features located along line 28 are scaled toappear further from the virtual observer located at viewpoint 12 thanfeatures located along line 20, less resolution is required to renderthe features located along line 28. Accordingly, by way of example andnot by way of limitation, a data base representing objects located alongline 20 might require one data string for each pixel. Because of thehorizontal and vertical scaling factors, one data string representing aparticular location along line 28 may represent, because of the reducedneed for resolution, the same information that required ten data stringsfor locations along line 20. Thus, it should be apparent that the databases may be optimized to provide realistic perspective at varyingdistances without requiring the large amounts of data storage processingand transfer that would be required if a single data base havingfeatures at a single resolution were used to render the entire scene.

[0034] The number of data bases having differing resolutions is limitedonly by the number of data bases that can be stored in the computer orgaming device storage device 4 or random-access-memory 3 (FIG. 1).Preferably, the number of data bases is approximately ten, with eachhaving approximately 75% less data than the data base representing thepreceding highest resolution available.

[0035] For most purposes, while a virtual observer in a simulation needsto be able to look out towards the horizon to detect oncoming terrainfeatures and adversaries, most events requiring operator response andinput occur in relatively close proximity to the virtual observer. Thus;in a preferred embodiment, the data base representing that portion ofthe gaming area 10 within a pre-determined distance of the viewpoint 12would necessarily be optimized around an intermediate resolution.

[0036] Since it is not unusual during a simulation to pass close by afeature of a terrain, such as a mountainside, use of a single databasewith one level of resolution may lead to visually unpleasing results.For example, as the virtual observer draws near to a particular featureof the terrain, the simulator may render the feature such that thefeature takes on a blocky and unrealistic appearance. Accordingly, inanother embodiment of the invention, still another database havingterrain features stored at higher resolutions for viewing at closedistances may be used to render the scene. As will be apparent to oneskilled in the art, the additional detail required to render theclose-up scene requires additional information to be stored to describethe appearance of the features located at each X and Y coordinate. Apreferred approach to reducing the amount of data necessary to rendersuch a close up visual scene is to incorporated expansion tokens intothe data string. Alternatively, associated with each X and Y locationcan be expansion tokens. As will be discussed more fully below, duringthe evaluation of the terrain visible to the virtual observer given theapparent heading elevation and viewpoint of the observer, the expansiontokens provide information to the processor or the computer of thegaming device instructing the processor to access and retrieveadditional data to enhance the display of the features stored at thatparticular location in the gaming area 10 to selectively increase theresolution of a particular feature. The features could be stored in alibrary of such features, for example, where the detail of amountainside is required to provide a realistic visual scene, suchdetail could be provided from a library of features representative of atypical mountainside, the particular feature being selected from thelibrary as indicated by the expansion token associated with theparticular location in the gaming area 10. This library of features maybe accessed by the processor 1 from the storage device 4, as required bythe processor 1 to render visual scenes in response to operator inputfrom the input device 5. Alternatively, the library of features may beloaded into the random-access-memory 3 either at the beginning of thesimulation, or at some time during the simulation prior to the librarybeing accessed by the processor 1. Pre-loading the library of featuresmay substantially increase processing speed and thus the rendering ofvisual scenes in response to operator inputs from the input device 5,providing a more realistic and visually pleasing experience. By properlyselecting the distance from the virtual observer that triggers theprocessor to select a different database to render the visual scene, thegame developer may provide the game player with an apparently seamlessrendering of visual scenes from very close to very distant from thevirtual observer.

[0037] In an alternative embodiment of the present invention, the gamingarea may also be represented by another set of data bases wherein thegaming area is divided into a number of regions called, for convenienceonly, quadrants. In one embodiment, a single quadrant data base is usedto represent the entire gaming area. In this embodiment, the gaming areais divided into areas requiring a 10×10 block of pixels to render on adisplay screen. Unlike the databases described above, where a heightvalue is associated with each pixel, in the quadrant data base, a singleheight value may be associated with the entire quadrant. The value ofthis height value may be, for example, the height of the highest featurelocated anywhere within the quadrant. Thus, the height of an entire10×10 block of pixels is represented by a single value.

[0038] As will be discussed more fully below, use of quadrants speeds upthe processing and rendering of the terrain data by providing a small,quickly accessible data base containing the maximum heights of alllocations within a certain area. Thus, the processor need only check theheight of a given quadrant to determine if any of the features in agiven quadrant are visible, rather than checking the height of eachindividual pixel within the quadrant.

[0039] The operation of the present invention will now be described withreference to FIGS. 2-5A and 5B. The position and heading of the virtualobserver 12 within the gaming area 10 are determined based on inputsfrom an operator. In normal game play, such inputs may be made throughthe pressing of keys on a keyboard or through signals received from amouse or joystick or other input device These signals are interpreted bythe processor in accordance with the programming instructions of thesoftware of the simulation program and result in the apparent motion ofthe virtual observer through the visual scene that is displayed on thedisplay 18. Such signals may, for example, change the direction ofmovement of the observer, or may, in a flight simulation, change theapparent elevation of the virtual observer above the gaming area.

[0040] Once the position, heading and elevation of the virtual observerhave been determined, that portion of the gaming area determined to bevisible to the vital observer is rendered in the display buffer 6, aswill be discussed in more detail below. Once the entire scene isrendered and stored in the display buffer 6, the contents of the displaybuffer 6 are written to the display 18. This process is repeated asoften as necessary to provide a flow of images on the display 18 thatprovide for a pleasing and realistic simulation.

[0041]FIG. 3 depicts an exemplary image rendered on the display screen18 by the present invention as viewed by an operator at a given instantof simulation or game play. Three horizon lines identified as c₁, c₂,and c_(n) representing a sequence of terrain features visible to avirtual observer are illustrated. It should be appreciated that thescreen dimensions given are selected merely for purposes of illustrationof the invention, and are nowise limiting. The horizon lines c₁, c₂, andc_(n) represent various topographical features, as they might appear onthe display screen 18, according to the data stored in the visual database 10.

[0042] In a preferred embodiment, the visual scene is rendered by theprocessor 1 by iteratively generating each pixel of the visual scene bybeginning with the pixel located at the bottom left of the displayscreen 18, identified in FIG. 3 by the array coordinates (0,200). Across-section of the display 18 screen in FIG. 3 is represented in FIG.4 by the line 54. This line 54 is representative of the first column ofpixels on the left side of the display screen as viewed by a gameplayer.

[0043] Once the position, heading and elevation 48 of the observer havebeen determined by the processor 1, the visual scene is rendered byfirst calculating a three dimensional step vector that describes theview of the observer passing through a single pixel, in this example,the pixel of the display identified as pixel (0,200). As will be obviousto one skilled in the art, this step vector 44 can be calculated todescribe the line originating at the viewpoint 12 and passing throughpixel (0, 200). Once this vector is determined, the process can thencalculate the extension of the vector to determine if the vectorintersects any feature of the terrain of the gaming area 10 that may bevisible to the virtual observer located at viewpoint 12. In oneembodiment of the invention, when vector 44 encounters a terrain featurethat would be visible, the height of the feature 40 is stored in amemory buffer for later reference. For example, once a feature isdetermined to be visible, a line is drawn, the length of the line beinga scaled height determined from the Z component of the vector 44 scaledto account for the elevation 48 of the virtual observer and the distancefrom the viewpoint 12 to the feature 40. Once this line is drawn, thenext y coordinate of the step vector is incremented and vector 45 iscalculated. In a preferred embodiment, the height of feature 40 has beenstored in a buffer, typically a portion of the random-access-memory 3,although the buffer may also be located in cache memory associated withthe processor 1, or in a file on the storage device 4, and is thusavailable to the processor to compare to the scaled height of thefeature as determined from vector 45. As can be seen from FIG. 2, thecalculation of vector 45 is not necessary, because its calculation willnot render any further features of the gaming area 10 than were renderedwith the calculation of vector 44. Thus, a substantial improvement inoverall processing speed is obtained using the present invention becausethe processor 1, taking into account the stored value of the height offeature 40, calculates the next incremental step vector to define vector46, rather than vector 45 or any other intermediate vectors, since thevectors passing through those pixels on the display screen 18 will addno further detail. This process is continued for each pixel on thedisplay screen until the entire first column of the display has beenrendered. The process is then repeated for the next column of thedisplay screen.

[0044] Alternatively, the X coordinate may be iterated, rendering anentire row of the display screen. In that embodiment, the display wouldbe rendered by generating the display beginning with the bottom row ofthe display screen 18, which represents the gaming area closest to thevirtual observer, and then generating each subsequent row until theentire visual scene is rendered in the display buffer 6, the last rowrepresenting the area of the gaming area visible to the virtual observerthat is farthest away from the virtual observer.

[0045] With this background established, the technique of the presentinvention may be described alternatively as follows. FIGS. 5A and 5B areflow charts representative of the technique of the present invention.Reference may also be taken to the following table (Table I) whichrepresents summarily the process which is explained below. TABLE IPROGRAM OPERATIONS A Allocate memory for data. B Load data into memory.C Clear the screen buffer. D Get observer position and heading. E Addstep vector to Observer position F Get quadrant data G Determine if thealtitude of the observer is less than the quadrant height H If altitudeis less, compute distance of sample point from the observer; else addquadrant step vector to position and repeat from step F I Select dataset for sampling J If the sample point is close to the virtual observer,expand the data K Sample the height data of the selected data set L Ifthe height is greater than the height of the last feature drawn, draw aline M Repeat from step E until all the visual scene is rendered in thebuffer N Write the display buffer to the display

[0046] As before, the processor renders the visual scene by computingthe position, heading and elevation of the virtual observer relative tothe gaming area 10. The first step vector is computed, and added to theobservers position, as indicated in box 72. Retrieving the height datain box 74 from the quadrant within which the pixel to be generated asdetermined in box 72 lies, the processor 1 next determines whether thereis any feature within the quadrant that would be visible as viewed alongthe step vector determined in step 72. If the processor 1 determinesthat no feature is visible within the quadrant, the program branches tobox 78. In box 78, a quadrant step vector is calculated. This vector isdifferent from the step vector in that the quadrant vector movesincrementally across quadrants, while the step vector iterates acrosspixels. Thus, in box 78, the calculated quadrant step vector is added tothe position of the virtual observer. Because the quadrant step vectortranslates the vector over a much larger distance than the step vector,the same amount of terrain can be generated using substantially fewersteps, thus resulting in a substantial improvement in processing speed.

[0047] If there is a terrain feature visible as determined in box 76,the distance of the sample point, or the point where the vector 44intersects the gaming area, from the virtual observer is calculated inbox 80. This distance is used by the processor to select an appropriatedata base wherein the elevation data contained in the data baserepresenting the height of features of the gaming area 10 has beenscaled to be representative of the scaling caused by the distance of thefeature from an observer. Since this data is already scaled fordistance, additional improvements in processing speed are obtainedbecause overdrawing of lines previously rendered is minimized. In apreferred embodiment, the number of data bases, each having sequentiallyless resolution, is limited only by the available capacity of thestorage device 4 or the random-access-memory 3 of the system. Forexample, a series of data bases beginning with a database representing alarge area of the gaming area and ending with a data base representingonly a small area of the gaming area wherein the height of any featureof the gaming area 10 can be represented by a single pixel could beused. For example, a series of ten databases, each database representinga smaller gaming area at higher resolution than the previous databasescould be used.

[0048] Alternatively, the processor 1 may determine that the distance ofthe sample point from the virtual observer is sufficiently small suchthat even using the data base having the highest resolution, a pleasingvisual display cannot be obtained. If this is the case, the processormay expand the data available in the data base using expansion tokensthat are stored within the data base and are associated with eachlocation in the data base. As stated previously, these expansion tokenscan be used to provide additional resolution in the visual display forthe locations close to the virtual observer. In a preferred embodiment,the expansion token is used as a pointer to a table of features orportions of features stored in the storage device 4 or therandom-access-memory 3 having a higher resolution than exists in thecurrently selected data base. Thus, the table of features could containa close up of the side of a mountain, or a bush, or a landing strip. Theprocessor 1 may then render this feature pixel by pixel, as for all theother terrain features. In the preferred embodiment, the feature may bemapped by the processor 1 into the display buffer 6 so that the featureis rendered at the location of the gaming area determined from thevirtual observer's position, heading and elevation. Such mappingprovides additional resolution without requiring a large increase inprocessing steps to render that portion of the visual scene close to thevirtual observer. The expanded data may also be stored in a bufferlocated in the random-access memory 3 or the storage device 4 for futurereference by the processor in further scene rendering, thus savingadditional processing steps that would be needed to re-render theexpanded data.

[0049] Once expansion of the data base is completed, or if expansion isnot necessary, as determined in box 84, the height of the feature as afunction of (X, Y) steps is sampled in box 88. If the sampled height isgreater than the height of the feature that is stored in the bufferdescribed above, a line 92 is drawn in the display buffer representingthe scaled height of the feature at that particular location as viewedby the virtual observer. If the sampled height is not greater than thestored height, then the line is not drawn, because it would simplyoverdraw a line previously drawn. By preventing the overdrawing oflines, a substantial gain in processing speed is obtained. If the lineis not drawn, the processes returns to box 70 and is repeated until theentire visual scene is rendered in the display buffer, and the contentsof the display buffer are written to the display.

[0050] It should be appreciated that the invention may be easilyimplemented in either software or hardware. Other modifications to thehardware or software can be made to the present invention withoutdeparting from the spirit and scope thereof. Accordingly, it is notintended that the invention be limited except by the appended claims.

I claim:
 1. A method of generating a perspective visual scene,comprising the steps of: a) determining the position of an observer inrelation to a gaming area bounded by the observer's field of view; b)incrementing the observer's position by one unit; c) determining if thedata quadrant at the new position is visible to the observer, wherein ifthe data quadrant is not visible, incrementing a quadrant step vector;d) determining a distance from the observer to an object of interest; e)selecting a database to be used dependent on the distance from theobserver to the object of interest; f) sampling the height data at thecurrent position; g) comparing the height data at the current positionwith the current elevation; and h) drawing a line for any part of theheight data that is above the current elevation; i) incrementing oneunit farther away from the observer; j) repeating steps b through iuntil the entire visual scene is rendered; k) displaying the visualscene on a display device.
 2. The method of claim 1 , wherein the stepof selecting a database further comprises: expanding an expansion tokenif the object of interest is closer to the virtual observer thanpredetermined distance; and rendering a feature represented by theexpanded expansion token.